Conversation
src/frontend/predicate.rs
Outdated
| Gt = 4, | ||
| Lt = 5, | ||
| Contains = 6, | ||
| NotContains = 7, |
There was a problem hiding this comment.
Are these still needed?
There was a problem hiding this comment.
Nope! Removed them, thanks for pointing that out :)
* merkletree: add keypath circuit * merkletree-circuit: implement proof of existence verification in-circuit * parametrize max_depth at the tree circuit * Constrain selectors in-circuit * implement merketree nonexistence proof circuit, and add edgecase tests * add non-existence proofs documentation in the mdbook, mv EMPTY->EMPTY_VALUE & NULL->EMPTY_HASH, dependency clean and public exposure methods * review comments, some extra polishing and add a test that expects wrong proofs to fail * Add circuit to check only merkleproofs-of-existence With this, the merkletree_circuit module offers two different circuits: - `MerkleProofCircuit`: allows to verify both proofs of existence and proofs non-existence with the same circuit. - `MerkleProofExistenceCircuit`: allows to verify proofs of existence only. In this way, if only proofs of existence are needed, `MerkleProofExistenceCircuit` should be used, which requires less amount of constraints than `MerkleProofCircuit`. * Code review --------- Co-authored-by: Ahmad <root@ahmadafuni.com>
* merkletree: add keypath circuit * merkletree-circuit: implement proof of existence verification in-circuit * parametrize max_depth at the tree circuit * Constrain selectors in-circuit * implement merketree nonexistence proof circuit, and add edgecase tests * add non-existence proofs documentation in the mdbook, mv EMPTY->EMPTY_VALUE & NULL->EMPTY_HASH, dependency clean and public exposure methods * review comments, some extra polishing and add a test that expects wrong proofs to fail * Add circuit to check only merkleproofs-of-existence With this, the merkletree_circuit module offers two different circuits: - `MerkleProofCircuit`: allows to verify both proofs of existence and proofs non-existence with the same circuit. - `MerkleProofExistenceCircuit`: allows to verify proofs of existence only. In this way, if only proofs of existence are needed, `MerkleProofExistenceCircuit` should be used, which requires less amount of constraints than `MerkleProofCircuit`. * Code review --------- Co-authored-by: Ahmad <root@ahmadafuni.com>
…ltiple middleware statements (in progress)
…t multiple statements
|
OK I think this is ready to merge. It does:
|
src/middleware/operation.rs
Outdated
| } | ||
|
|
||
| pub fn args(&self) -> Vec<Statement> { | ||
| pub fn args(&self) -> Vec<OperationArg> { |
There was a problem hiding this comment.
My suggestion would be to change this so that args still returns Vec<Statement>.
And instead of introducing an OperationArg, add a new method Operation::aux(&self) -> OperationAux which returns the auxiliary data of the operation.
enum OperationAux {
None,
MerkleProof(MerkleProof),
}I think this would simplify things a bit.
Then on the frontend I would suggest doing something similar.
pub struct Operation(pub OperationType, pub Vec<OperationArg>, pub OperationAux);And keep the frontend::OperationArg untouched.
And the same idea in mock_main
ed255
left a comment
ed255
left a comment
There was a problem hiding this comment.
I've taken a quick look to see the changes related to this suggestion #145 (comment)
and this LGTM!
|
(Responding to a question from a call this morning) Why did I implement this new logic manual_compile_st_op() for DictContains (to introduce a ValueOf statement for EMPTY_VALUE), when we already have a method for converting literal statement arguments to ValueOf constants? Because I want the literal to be introduced at a different time: I want it to be introduced only in the middleware pod statements, not in the frontend pod statements. In other words: I want the frontend statements to contain a single statement ... Are you (@ax0 @ed255 @arnaucube) suggesting that I redesign it, so the frontend statements look like and the backend looks the same as before I guess this would make the code simpler but the frontend pods would have an unexplained ValueOf statement... |
|
We discussed the possibility of having a canonical hardcoded ValueOf statement with key=EMPTY_VALUE (or some other reserved key) and value=0. And then we can always assume this ValueOf statement exists and then turn We also discussed merging this PR as is so that we can advance and keep the discussion open and resolve this later. And while writing this I thought of a new solution: add BTW shouldn't it be |
yes, I fixed it :) |
|
I won't be able to do much work on this for at least a couple days so... maybe just merge now and discuss later? |
5 participants
DRAFT
Add contains statements for frontend types:
DictContains
DictNotContains
SetContains
SetNotContains
ArrayContains
Work in progress -- will need to create duplicate frontend::Operation and middleware::Operation, and force the compiler to do the conversion.